tips:
presto 0.208连接hive有不少坑，请尽量不要选择这个版本。 presto0.208以上的版本，jdk需要8_151+.
问题还原：
集群环境
hive 2.3.3
presto 0.208
hadoop 2.6
集群有张hive表使用hive-cli查询是OK， 但是使用presto cli进行select * from table_name 同样的sql 语法查询会报错，error stack大致如下：
1 |
|
后面进一步排查，发现presto-cli中，查询的sql只要指定部分int/bigint类型的字段就会报错，对其他string类型的字段不报错。
排查思路
step 1:
hive-cli中执行show create table table_name,得到表结构，并在自己的测试环境创建同样的表test_table;
step 2:
从hive表对应的hdfs文件出导出部分文件，在hive-cli中执行load data local 语句，导入抽样数据到test_table中
step 3:
hive-cli和presto-cli中分别执行查询语句看问题是否复现
（hive-cli中 执行 select * from test_table limit 1， 返回结果正常， presto-cli中执行报错，问题复现，同时发现只有查询表中的int/bigint类型字段会出问题）
step 4:
step1的时候发现表内容的存储格式是orc ,所以执行 hive –orcfiledump /user/hive/warehouse/test_table/part-00000-4ae99c5d-9fec-47ab-a19c-c970f4ec40be-c000.snappy.orc 看orc文件的统计信息
step4发现异常： table中定义为int,bigint类型的字段在步骤4的类型统计部分显示全部都是string类型，所以就怀疑是orc文件的文件部分字段类型和hive table中定义的不一致造成presto 在读取相关orc文件的时候报错。至于为什么hive-sql读取不报错，可我是hive对orc文件的处理和presto不一样吧。
抱着这 样的猜想，决定去进行一次实验，去构建一个表结构定义和orc文件字段定义类型不一致的场景， 实验过程如下：
错误复现实验
创建测试表test_string
tips:这里创建test_string表是为了将表中的orc文件拷贝到另外的test_int表
create table :
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
`server` string,
`uid` string)
ROW FORMAT SERDE
'org.apache.hadoop.hive.ql.io.orc.OrcSerde'
STORED AS INPUTFORMAT
'org.apache.hadoop.hive.ql.io.orc.OrcInputFormat'
OUTPUTFORMAT
'org.apache.hadoop.hive.ql.io.orc.OrcOutputFormat'
/* 或者可以简写为如下
CREATE TABLE `test_string`(
`server` string,
`uid` string)
STORED AS orc
*/
hive-cli中执行show create table test_string输出如下:
1 | CREATE TABLE `test_string`( |
向test_string表导入部分数据：
1 | hive-cli> |
退出hive-cli,查看test_string在hdfs上的orc文件信息概览
hadoop fs -ls /user/hive/warehouse/test_string (发现其下有一个000000_0,这是test_string的orc存储文件,输出如下）
1 | Found 1 items |
hive –orcfiledump /user/hive/warehouse/test_string/000000_0 （执行这个命令查看orc文件的概览信息, 输出如下）：
1 | Processing data file /user/hive/warehouse/test_string/000000_0 [length: 323] |
创建测试表test_int
create table (注意，这里创建表的uid字段是int类型)
2
3
4
`server` string,
`uid` int)
STORED AS orc
此时，hive-cli中执行show create table test_int,输出内容内容如下：
1 | CREATE TABLE `test_int`( |
试着将test_string表的hdfs orc文件移动到test_int表的location下（这里是hdfs://Ucluster/user/hive/warehouse/test_int）
1 | load data inpath 'hdfs://Ucluster/user/hive/warehouse/test_string/000000_0' overwrite into table test_int; |
此时退出hive-cli ,查看test_int表的orc文件概览信息
hive –orcfiledump /user/hive/warehouse/test_int/000000_0
1 | Processing data file /user/hive/warehouse/test_int/000000_0 [length: 323] |
hive/presto查询结果对比
经过上面两个建表的步骤，我们就得到了一个符合预期的test_int表（表的定义中uid为int类型， 表的hdfs orc文件中的uid的类型为string
进入hive-cli，进行查询测试：
2
3
4
5
OK
server1 1
server2 2
Time taken: 4.186 seconds, Fetched: 2 row(s)
1 | hive> select uid from test_int; |
进入presto-cli进行测试：
presto-cli –debug –server hadoop-master1:28080 –catalog hive –schema default 这里的hadoop-master1:28080为presto coordinator的主机名和监听端口，database使用默认的default库， 从结果发现，查询test_int表的string 类型字段是ok的，查询int类型的uid字段会报错。
1 | // presto 查询string 类型的字段ok |
1 | // 查询int类型的字段报错，复现之前的问题。 |
测试总结
如果想让hive以orc格式存储的表能正常在presto中查询，最好保证orc文件的字段类型定义和create table时的定义一致，否则，有可能会造成hive-cli中查询正常，在presto-cli 中查询异常的情况。 特别是在从别处拷贝orc文件过来的时候，需要先做一下类型比对。
ps: 为何hive-cli中查询可以兼容字段类型不一致，而presto中确不行，就需要看presto的源码了。之前从网上看文档，presto在读取hdfs orc文件是进行了一些优化的，有了解细节的大大可以告诉我一声哈。另，测试是发现，test_int表在hive中查询uid字段，如果有非法字段，会显示为null.